Add Okiff and GREENNET distributors and the CUBA IoT Platform case study - #643

"in production experience" isn't idiomatic English — I can't quite tell what it's claiming. If it means the number is drawn from deployments already running, "Monitored generator nodes in production" says that cleanly; if it's about CUBA's track record, "Generator nodes monitored in production deployments" works.

Separate nit, take it or leave it: all three labels here are capitalized, while the great majority across the other case studies are lowercase noun phrases ('monitoring points installed', 'sensors installed', 'years of experience'). There are a couple of capitalized outliers already, so this isn't a rule — just noting it if you want the stat row to match its neighbours.

The quote is missing its full stop after "before they become outages". I checked all 41 quote texts in src/data/case-studies/ — this is the only one without terminal punctuation.

On line 34, "CTO in Skif Trade LLP" reads as a non-native construction; English takes "at" for a company. None of the 21 sibling role values use "in" — the established shapes are 'Founder, ACTE Technology', 'PM, SOLANDTEC', 'Founder & CEO of TJK-Solutions'. 'CTO at Skif Trade LLP' would fit. I know you flagged the attribution as verbatim-from-design, but this one is a grammar slip rather than a debatable phrasing choice, so it seems worth correcting even in verbatim copy. ("SMALL, SPAR supermarkets" is also opaque to a reader who doesn't know those chains — a word like "retail chains" would help, if the content owner is fine with deviating.)

"e-mail" here and on line 71 are the only two occurrences of the hyphenated spelling anywhere in src/ — the other 179 are "email". Worth matching.

I think images 2 and 3 are paired with the wrong blocks. This block's text is about the asset model, the fleet table and the per-generator detail panel that "consolidates engine state, generator electrical parameters, mains parameters, breaker states, runtime, and control mode" — that is precisely what cuba-iot-platform-3.webp shows (left rail with Engine/Generator readings, Generator and Mains tables, breaker indicators). cuba-iot-platform-2.webp is four historical trend charts with an "Engine stop" annotation, which belongs with block 4. Your own alt strings say as much: image 2's is "Generator telemetry charts", image 3's is "…engine, generator, and mains panels".

Caveat: you built this 1:1 from the design, so it's quite possible the pairing is faithful and the mismatch originated there. In that case this is a question for the designer rather than something to fix in the PR — but the mismatch is real either way, so it's worth resolving before it ships.

Two related observations while you're here. Images 2 and 5 are both crops of the same historical dashboard that image 4 shows in full, so blocks 2, 4 and 5 currently render three near-identical chart grids — and a straight 2↔3 swap would leave the Rule Engine block holding image 2, which still shows no alarm or notification. A rule-chain or Telegram/e-mail notification screenshot would carry more weight there. Separately, image 3 has a Russian-language UI ("Карта" / "Таблица") on an otherwise English marketing page — worth an English capture if one is obtainable.

Two small copy things in this block. "maintenance planning by actual runtime" wants "based on actual runtime". And "Operators can analyze mains outage, generator start, fuel refill, engine stop, voltage, current, power…" mixes bare singular event nouns with mass nouns — pluralizing the events ("mains outages, generator starts, fuel refills, engine stops") makes the list read consistently.

The comment hard-codes the page size, but PAGE_SIZE = 9 actually lives in src/pages/case-studies/index.astro — and is declared twice there, once in the frontmatter (line 8) and once inside the client <script> (line 172). So "first card of page 2" rests on three mentions of the number 9 across two files, none of which references the others.

Exporting a single CASE_STUDY_PAGE_SIZE from this module and importing it in both spots would collapse that; I checked, and the client script is a bundled module (it already does import { updatePagination } from '@components/Pagination/pagination-client'), so the import works there. Low priority though — the bigger half is the why: the comment says what the placement does but not what it's for, so the next person tidying the array back to newest-first has no way to tell whether that's safe.

The "Adding a case study?" checklist above still lists two steps plus the optional cardLogoHeights entry — logoUnfiltered is now the other optional per-study logo knob and isn't mentioned. Without a bullet there, the next person shipping a logo that already has its own dark treatment will rediscover the white flatten by eye rather than by reading the list.

There's also a mild tension with the cardLogoHeights comment ("we keep the card override here rather than on the data itself") now that a card-affecting override does live on the data. One sentence drawing the line — card-only sizing here, cross-surface treatment on the data — would keep that rationale coherent.

Optional, and I wouldn't hold the PR for it: the name describes the CSS mechanism ("we don't run a filter") rather than the property of the asset ("this logo already ships light-on-dark artwork"), which is what a data-file author actually knows. Something like logoIsLightOnDark would let the data file be written without knowing how the card is styled. The doc comment covers the gap well enough that this is really just a preference — a boolean is the right shape either way.

Declaring both regions does make Georgia reachable from the Asia filter as intended. One side effect worth being aware of: REGION_OFFERED_COUNTRIES in src/data/partners/index.ts collects all countries a distributor names for each region it declares, without intersecting against REGION_MEMBERSHIP. So picking region "Asia" now offers Ukraine and Poland in the country dropdown, and "Asia + Poland" returns GREENNET.

Basari Muhendislik already behaves the same way (Tunisia and Libya appear under Asia), so this is pre-existing behavior that your entry widens rather than introduces — and fixing it would change results for the existing entries too. Not something to do in this PR; worth a separate ticket if the dropdown noise bothers anyone, since REGION_MEMBERSHIP already has everything needed to intersect.

Nit: the same concept gets two names across the two surfaces — cs-logo-unfiltered here and cs-contact-logo-unfiltered in ContactCTA.astro. Nothing collides, since each is scoped under its own base class, but settling on one (cs-logo-unfiltered reads better as the generic modifier) makes the pair greppable as a single feature.

Adding Middle East is what makes Syria reachable under the new rule, but keeping Asia alongside it leaves a region HADEX covers nothing in — the table classifies Syria under Middle East only. So this line creates one of the 8 entries the new findDanglingRegions warning reports, in the same PR that adds the warning.

Was regions: ["Middle East"] the intent? I checked what that changes and it's inert everywhere except the thing you'd want: the assertion still passes, the warning for HADEX goes away, and the country dropdowns come out byte-identical (Syria was never offered under Asia anyway, since the new intersection excludes it). The only visible effect is that HADEX stops appearing under the Asia filter's "All countries" view — which is the correct outcome if Syria isn't Asian per our own table.

The Vehi.kz LLP change below is clean by contrast — both Asia and Europe have named countries in them.

I ran this against the dataset as it stands on this branch and it fires immediately, for 8 entries:

[distributors] regions declared without any named country in them (card vanishes once a country is picked):
  Clever Platform → Asia; HADEX → Asia; LTS-Connecting Things → Asia; qnectd → Europe;
  Quantova → Asia; Spectrum Smart Solutions Systems LLC → Asia; Kar-Tel LLP → Middle East;
  IoT Experts → Asia

A check that's noisy on the day it lands stops carrying signal within a build or two, and then it won't catch the case it was written for. Six of the eight are the same shape — a Middle-East-only country (Saudi Arabia, Syria, UAE, Israel) with a leftover Asia claim.

I simulated dropping every dangling region to see what it would cost, and mechanically it costs nothing:

8 entries change (e.g. Clever Platform ["Middle East","Asia"] → ["Middle East"],
                       Kar-Tel LLP ["Asia","Europe","Middle East"] → ["Asia","Europe"])
assertion:                 passes, zero warnings
empty (region, country):   none
unreachable distributors:  none
country dropdowns:         identical — no option gained or lost

So the only real question is editorial: should those 8 cards keep showing under a region whose countries they don't serve, in the "All countries" view? That's a data-owner call, which is exactly why a warning rather than an error is the right shape here — I'd just rather the channel started silent. Clearing the HADEX one (see my note in distributors.ts) is yours since this PR created it; the other 7 are pre-existing and fine as a follow-up ticket.

If some of those claims turn out to be deliberate, there's a good in-repo precedent for saying so: src/data/case-studies/index.ts:97 keeps its equivalent warning quiet with an explicit FEATURED_ONLY_SLUGS allowlist.

This new bullet sits a little awkwardly next to the first convention in the same docblock — "Middle East is its own region, not a subset of Asia — a distributor covering both lists both". That sentence is very likely why 6 existing entries list Asia for Middle-East-only countries: read as "Middle East countries are Asian too, so list Asia", it produces exactly the entries the new dangling-region warning flags. Under the new bullet, those same entries are wrong.

So the table and those 6 entries disagree about whether Saudi Arabia / Syria / UAE / Israel are Asian, and this PR adds the check that surfaces the disagreement without settling it. Worth settling it here in one clause — either those countries stay Middle-East-only and the entries drop Asia (which is what the new rule implies), or they get dual-classified in the table the way Turkey and Georgia already are. Right now a reader following bullet 1 and a reader following bullet 4 will write the entry differently.

Still unresolved: the fragility half is fixed — the client script reads data-page-size now, so the page size no longer lives in three unlinked places. But the part I'd flagged as the more important one is still open: the comment says what the placement does, not what it's for. The next person tidying this array back to newest-first has no way to tell whether that's safe, which is the failure mode the comment exists to prevent.

One clause would close it — why page 2 specifically, rather than the top of page 1 where a new case study would normally go? That reasoning is the only thing stopping someone from "fixing" the ordering later.

(No need to put the 9 back or export the constant — data-page-size was the right call, and it matches what PartnerLibrary.astro already does.)

Re-raising the part of my earlier image note that the swap didn't cover. Blocks 2 and 3 now hold the right screenshots relative to each other, but this block is specifically about rule chains, alarm activation and Telegram/SMS/email notifications, and the image it lands on is four historical trend charts (coolant temperature, oil pressure, mains power, battery voltage) with an "Engine stop" annotation — no alarm, no rule chain, no notification anywhere in the frame.

So the strongest claim in the section is the one with no supporting visual. A rule-chain screenshot, an alarms table, or a Telegram/email notification capture would carry real weight here. If nothing like that is obtainable from the customer, dropping the image from this block would still read better than an unrelated one.

The other re-raise, now more visible than it was before the swap. Comparing the four screenshots: image 4 is the full 12-tile historical dashboard, and images 3 and 5 are both crops of that same dashboard — image 3 is its Coolant Temperature / Oil Pressure / Mains power / Battery Voltage tiles, image 5 its Mains current / Mains power / Generator current / Generator power tiles. Blocks 3, 4 and 5 therefore render three overlapping views of one dashboard, with image 4 containing both of the others.

What makes it worth acting on rather than filing as a nit is what the cropping costs. In image 5 the whole top row (Mains current, Mains power) sits flat at zero. In image 4 that same flat line is legible, because the annotation "Power network shutdown" is right there explaining it — mains died, which is the whole reason the generator ran. Cropped away from that annotation it just reads as an empty chart, so the crop loses the one thing that made the data tell a story.

And this block is the retitled architecture block — gateways polling controllers over Modbus and publishing telemetry. A dashboard crop, half of it flat, is a weak illustration for it; an architecture or topology diagram is the natural fit and would also break up three consecutive chart grids.

If the design supplies exactly these five crops then this is a question for the designer rather than a change to make here — but with block 2's screenshot re-exported already, 3/4/5 is now the weakest part of the page's visuals.